Nautilus 1992 July/Nautilus-3-8/Nautilus-3-8.bin/Tools & Utilities/Techy Stuff/Doco ƒ/CSMP ƒ/CSMP-V1-085.TXT

Text File | 1992-06-30 | 51.8 KB | 1,455 lines

C.S.M.P. Digest             Mon, 18 May 92       Volume 1 : Issue 85

Today's Topics:

    Garbage in my GWorld's - help!
    Password specification for AppleEvents?
    Mac SCSI Disk Spin-up
    Is ALIGN broken in MPW assembler?
    IM IV Sound Mgr error fix...where?
    Specifying -model for MPW C++
    diskInserted events
    THINK C 5.0.2 questions on syntax
    How to guarantee the colors I want when my app runs?
    ThinkPascal
    Zortech C++


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The digest is a collection of articles from the internet newsgroup comp.sys.
mac.programmer.  It is designed for people who read c.s.m.p. semi-regularly
and want an archive of the discussions.  If you don't know what a newsgroup
is, you probably don't have access to it.  Ask your systems administrator(s)
for details.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Kenneth Knight)
Subject: Garbage in my GWorld's - help!
Date: 9 Apr 92 09:04:15 GMT
Organization: Instructional Technology Laboratory, University of Michigan

I am designing a program that does some fairly advanced graphics for work. The
program is meant to provide an interactive means towards image compression
(display both before and after images and let the user modify them). The image
data are stored in Graphics World's (GWorld's). There are three main GWorlds:
the before image, the after image (compressed before image), and a buffer for
the Undo command (a fourth is created sometimes for things like psating). My
problem is that it appears that garbage is being stored in the second (and
probably thrid and fourth) GWorld's that I create. For example, the before
image seems to draw to the left side of the main window perfectly , but the
after image is crud (it should , on startup, be a large white rectangle since
the before image has not been compressed). Right now the GWorld's are declared
globally like this:
     GWorldPtr   gAfterWorld, gBeforeWorld, gUndoWorld, gPasteWorld; /* with
proper extern GWorldPtr statements in the other files that use these
variables. */

If I create the GWorlds in the order: gBeforeWorld, gAfterWorld, gUndoWorld I
immediately see garbage in the second GWorld. If, however, I create the
GWorlds in the same order as they are declared the garbage in the second world
is less visible (though I believe still there , also I think garbage might be
in the first world, too). The three main GWorlds are all the same size (the
picture frame rectangle that is being displayed) and of the same depth (8 or
32 bits per pixel). This problem appears no matter what I pass to my creation
routine (essentially a call to NewGWorld with the proper parameteres set).

As far as I can tell the problem is NOT with any of my drawing routines, but
with the GWorld's themselves (NewGWorld appears to be working fine, no error
is returned and the partition I've given the application in tests is far
greater than it needs to be). Specifically, the portPixMap base address of,
say gAfterWorld in the first example, is either just slightly before or after
the portPixMap base address of gBeforeWorld. The result is a mangled image
appearing on the right side of the display (i.e. the pixel maps of gAfterWorld
and gBeforeWorld are overlapping).

What am I doing incorrectly? Can anyone suggest things to check (the params
passed to the creation routine and then NewGWorld are coorect, the GWorld
structures that are returned - with the exception of the portPixMap^^.baseAddr
- - seem valid (e.g. proper rects, regions, rowBytes), and the drawing routines
are drawing with the right rects (the CopyBits call has the proper params and
I am quite sure that no colorizing errors are taking place - I insure that the
foreground color is black and the background color white before calling
CopyBits))?

Thanks in advance....

   ** Ken Knight **
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Matt Mora)
Date: 9 Apr 92 19:38:21 GMT
Organization: SRI International, Menlo Park, California

Are you erasing your gworlds before you are using them?

Matt


- --
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________

+++++++++++++++++++++++++++

From: [e-mail] (P. Hawthorne)
Date: 10 Apr 92 11:39:24 GMT
Organization: Reed College, Portland OR


  [e-mail] (Kenneth Knight) writes:
. My problem is that it appears that garbage is being stored in the second
.(and probably third and fourth) GWorlds that I create.
. Specifically, the portPixMap base address of, say gAfterWorld in the
. first example, is either just slightly before or after the portPixMap
. base address of gBeforeWorld.

    Gee, this sounds a lot like the snow I find in my gWorlds after a
suspend or resume event, particularly involving the desk accessory
layer where the refCons of windows change fast and furious.
    Judging from how drastically different 32-Bit QuickDraw runs on
System 7 as opposed to 6.0.7, well... Are you using System 7?
    I suspect that you may not be dereferencing the pixMap handle in just
the right way. And then, it could be entirely natural for that to happen.
Ours is not to wonder why... ours is just to code and sigh.
    Look at it another way: Are you locking the gWorld while drawing?
Are you enlocking them across event polling?
    If all else fails, take a look at what it is you are trying to draw
and bitblit in the first place.

    Theus ([e-mail])

+++++++++++++++++++++++++++

From: [e-mail]
Date: 10 Apr 92 19:34:52 GMT
Organization: Adept Solutions

In article <[e-mail]>
[e-mail] (Kenneth Knight) writes:
> I am designing a program that does some fairly advanced graphics for work.
The
> program is meant to provide an interactive means towards image compression
> (display both before and after images and let the user modify them). The
image
> data are stored in Graphics World's (GWorld's).

<< Much stuff deleted>>

Are you sure you are using SetGWorld & GetGWorld, and NOT SetPort & GetPort..
(Even though GWorlds are typed as CGrafPtr's + stuff, you have to use the
proper routines.)
This bit me a few years ago, (left a nasty scar :), but the reason that I
remember about it to this day was that it ALMOST worked, but there was SOME
GARBAGE!!! And it too seemed rather random..

Also, LockPixels is a big must, too!
- --
Roy Lovejoy      | internet:  [e-mail]
Head RGB Guy     | AppleLink: adept
Adept Solutions  | CIS:       72447,1447
.................| dual certified developer: NeXT & Apple ;)

+++++++++++++++++++++++++++

From: [e-mail]
Date: 16 Apr 92 07:47:15 GMT
Organization: Adept Solutions

In article <[e-mail]> [e-mail] (P. Hawthorne)
writes:
>
>   [e-mail] (Kenneth Knight) writes:
> . My problem is that it appears that garbage is being stored in the second
> .(and probably third and fourth) GWorlds that I create.
> . Specifically, the portPixMap base address of, say gAfterWorld in the
> . first example, is either just slightly before or after the portPixMap
> . base address of gBeforeWorld.
>
> << Other illuminations deleted>>
>     Theus ([e-mail])

Another thought is that there is a bug in 6.0.7 that was fixed in 7.0, that
being that if you resize/offset a GWorld under 7.0, the clipRgn & visRgn get
resized/offseted along with it. Under 6.0.7 one of them (I forget which), does
not.  Big headache!

Cheers.
- --
Roy Lovejoy      | internet:  [e-mail]
Head RGB Guy     | AppleLink: adept
Adept Solutions  | CIS:       72447,1447
.................| dual certified developer: NeXT & Apple ;)

---------------------------

From: [e-mail] (Tim Endres)
Subject: Password specification for AppleEvents?
Date: 13 Apr 92 16:07:33 GMT
Organization: ICE Engineering, Inc.


When I send an Apple Event, the first execution puts up the password
prompt dialog box. This is fucked for background execution. How do
I send an Apple Event and specify the password to avoid this dialog?


tim endres - [e-mail]  -or-  uupsi!tbomb!time
ICE Engineering, Inc. - Phone [phone] - FAX [phone]
8840 Main Street, Whitmore Lake, MI  48189
USENET - a slow moving self parody... ph

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 13 Apr 92 19:37:17 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.com> [e-mail] (Tim Endres) writes:

   When I send an Apple Event, the first execution puts up the password
   prompt dialog box. This is fucked for background execution. How do
   I send an Apple Event and specify the password to avoid this dialog?


The f-word is exactly how I feel...

This has been beaten to death before. The short answer is that
THERE IS NO WAY; some people at Apple feel this is bad, and should
be fixed; until it is, ...

The long answer is you can allow guest access, and use the
neat hack called "AutoGuest INIT."

- --
"You should meet yourself someday. I'm sure you would hate it."
- - Me: [e-mail]; Jon W{tte (The Diplomat - NOT!)

+++++++++++++++++++++++++++

From: [e-mail]
Date: 15 Apr 92 05:10:11 GMT
Organization: Wright State University

In article <[e-mail]>, [e-mail] (Jon W{tte) writes:
> .com> [e-mail] (Tim Endres) writes:
>
>    When I send an Apple Event, the first execution puts up the password
>    prompt dialog box. This is fucked for background execution. How do
>    I send an Apple Event and specify the password to avoid this dialog?
>
> The f-word is exactly how I feel...
>
> This has been beaten to death before. The short answer is that
> THERE IS NO WAY; some people at Apple feel this is bad, and should
> be fixed; until it is, ...
>
> The long answer is you can allow guest access, and use the
> neat hack called "AutoGuest INIT."

Another alternative (in certain situations) is to use the PPC toolbox
directly. PPCStart skips the authentication step of StartSecureSession.
PPC also gets around the 64K limit. Of course if you need AppleEvents,
you need AppleEvents...

o----------------------------------------------------------------------------o
| John B. Matthews, [e-mail], disclaimer:= myViews <> WSU |
| "I'm a commensal .sig virus, indistinguishable from an ordinary organelle."|
o----------------------------------------------------------------------------o

+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 16 Apr 92 20:09:37 GMT
Organization: Apple Co.

In article <[e-mail]>, [e-mail] (Tim Endres) writes:
>
> When I send an Apple Event, the first execution puts up the password
> prompt dialog box. This is fucked for background execution. How do
> I send an Apple Event and specify the password to avoid this dialog?

You patch a mess of shit and/or burrow under the AE manager.  Greg Anderson
already did this in his AutoGuest INIT & library.  It is available on the
Developer CD.  It only allows Guest access this way though.  Anything
requiring a password is still out of bounds for a bg only app.  I think we
need a programmatic way of providing the user name and password, but it
doesn't exist.

In short, we know it's fucked.  We're trying to get it fixed.

Jon

My opinion.  My language.  My ass...

+++++++++++++++++++++++++++

From: [e-mail] (Greg L. Anderson)
Date: 16 Apr 92 23:03:49 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Jon Pugh) writes:
>You patch a mess of shit and/or burrow under the AE manager.  Greg Anderson
>already did this in his AutoGuest INIT & library.  It is available on the
>Developer CD.  It only allows Guest access this way though.

For the record, there were quite a few people who worked on overcoming this
problem; I just rolled it all together.  AutoGuest should be avoided when
possible, though; it's not guarenteed to work with future versions of
the system.

>Anything
>requiring a password is still out of bounds for a bg only app.  I think we
>need a programmatic way of providing the user name and password, but it
>doesn't exist.
>
>In short, we know it's fucked.  We're trying to get it fixed.

Amen...
- --
=====================   ===========================   =====================
Greg Anderson           Apple Computer, Inc.            O    Ponnuki    O
Macintosh Bodhisattva   Macintosh System Software      O O  is  ideal  O O
[e-mail]       Finder Team                     O     shape     O
=====================   ===========================   =====================

---------------------------

From: [e-mail] (Trevor Henthorn)
Subject: Mac SCSI Disk Spin-up
Date: 16 Apr 92 19:34:40 GMT

I have a SCSI disk here which requires a SCSI spin-up (or restart)
command before it will spin up.

Most computers other than the Mac send that spin-up command when they boot.

Does anyone know of any drivers or utilities for the Mac that send
that spin-up command? I have seen spin-down utilities.


Thanks,

Trevor Henthorn

please e-mail

[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Gary Kessler)
Organization: Digital Equipment Corporation
Date: 16 APR 92 14:20:44


In article <[e-mail]>, [e-mail] (Trevor Henthorn) writes...
>I have a SCSI disk here which requires a SCSI spin-up (or restart)
>command before it will spin up.
>
>Most computers other than the Mac send that spin-up command when they boot.
>
>Does anyone know of any drivers or utilities for the Mac that send
>that spin-up command? I have seen spin-down utilities.
>
>
>Thanks,
>
>Trevor Henthorn
>
>please e-mail
>
>[e-mail]
What kind of disk is it??  There are a couple of "freeware" SCSI init's the
send spin-up commands to the disks or you might be able to modify the mode page
to set the spin-up on power-up bit.  All depends on the drive.

Gary Kessler


---------------------------

From: [e-mail] (Haydn Huntley)
Subject: Is ALIGN broken in MPW assembler?
Date: 15 Apr 92 14:25:56 GMT
Organization: Indiana University, Bloomington


I'm porting a program from Unix to the Mac, and part of it is written
in assembler.  In the assembler, there are statements like "ALIGN 8",
to align the function entry points on 8 byte boundaries.  The MPW
assembler has an align directive, and the files assemble just fine.
However, when the code is run, those entry points are only aligned on
2 byte boundaries!

Does anyone know why this is broken or have any ideas on how to fix
it?

BTW, I'm using MPW 3.0 on a Mac IIcx, and in another week version 3.2
should get here.

Thanks in Advance,

- --Haydn
- --
;;  *****************************************************
;;  *  Haydn Huntley    [e-mail]  *
;;  *****************************************************

+++++++++++++++++++++++++++

From: [e-mail] (Doug McNought)
Date: 15 Apr 92 17:43:26 GMT
Organization: California Institute of Technology

In article <[e-mail]> [e-mail] (Haydn Huntley) writes:

   I'm porting a program from Unix to the Mac, and part of it is written
   in assembler.  In the assembler, there are statements like "ALIGN 8",
   to align the function entry points on 8 byte boundaries.  The MPW
   assembler has an align directive, and the files assemble just fine.
   However, when the code is run, those entry points are only aligned on
   2 byte boundaries!

I don't use MPW, but my suspicion is that it's related to the original 68000
alignment properties. Since the 68K has a 16-bit bus, word alignment is the
only kind of alignmant that exists. On the later chips, you can use any
you want, but 32-bit accesses do best when longword-aligned. The system
software is restriced by the original architecture--many structs used by
the system are only word-aligned, so C structs which on a unix box would
be longword aligned for efficiency are constrained to only word alignment.
Your problems with the MPW assembler may be related to this--sorry I'm not
better informed on the particulars.
regards,
doug
- --
<><><><><><><><><><><><><><><>Go Orioles<><><><><><><><><><><><><><><><>
<> Doug McNaught                          [e-mail] <>
<>  Help!!! I'm addicted to *Spaceward Ho!* Is there a support group? <>
<><><><><><><><><><><><><><><>Go Orioles<><><><><><><><><><><><><><><><>

+++++++++++++++++++++++++++

From: [e-mail] (Ira Ruben)
Date: 16 Apr 92 20:19:22 GMT
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] (Haydn Huntley) writes:


>I'm porting a program from Unix to the Mac, and part of it is written
>in assembler.  In the assembler, there are statements like "ALIGN 8",
>to align the function entry points on 8 byte boundaries.  The MPW
>assembler has an align directive, and the files assemble just fine.
>However, when the code is run, those entry points are only aligned on
>2 byte boundaries!

>Does anyone know why this is broken or have any ideas on how to fix
>it?

The following is the output from MPW Asm for a little test program I
wrote:

00000                                 proc
00000   01                            dc.b    1
00001   0000 0008                     align   8
00008   0002                          dc.w    2
0000A                                 end

According to the addresses on the left the align did indeed align to
the desired boundary.  Check your asm listing.

Ira Ruben
Apple Computer, Inc.


---------------------------

From: [e-mail] (howard l. berkey)
Subject: IM IV Sound Mgr error fix...where?
Date: 15 Apr 92 16:30:55 GMT
Organization: The Orbital Mind Control Lasers


Hi all!
    I understand that the chapter on the Sound manager in IM IV (four,
not six) is somewhat, ah, misinformative and I was wondering if the correct
info is available on an FTP site... I looked on sumex but didn't see it.  Also
I was wondering if Apple/Addison-Wesley/apda or some philanthropist was going
to produce an edition of IM IV with the correct information.
Thanks!
    -Howard




- -------------------------------------------------------------------------
You can't stop him, he's too insane!
                    Some have to dance, Some have to kill
Howard Berkey, permanent undergrad                [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Paul Potts)
Organization: Instructional Technology Laboratory, University of Michigan
Date: Thu, 16 Apr 92 18:21:33 GMT

In article <[e-mail]> [e-mail] (howard l. berkey) writes:
>
>Hi all!
>    I understand that the chapter on the Sound manager in IM IV (four,
>not six) is somewhat, ah, misinformative and I was wondering if the correct
>info is available on an FTP site... I looked on sumex but didn't see it.  Also
>I was wondering if Apple/Addison-Wesley/apda or some philanthropist was going
>to produce an edition of IM IV with the correct information.

IM-6 (VI, six : > ) is much improved, although still a little hard to follow
as far as organization goes. Beyond that there is the draft chapter for a
revised Inside Macintosh that is available on ETO disks and (maybe) on
Develop or the Developer's CDs.

I've been able to get along quite well with IM-6.
- --
Paul Potts - [e-mail]
Un damne' descendant sans lampe,/ Au bord d'un gouffre dont l'odeur
Trahit l'humide profondeur,/ D'e'ternels escaliers sans rampe...
   -Baudelaire on DOS/Windows programming

---------------------------

From: [e-mail] (John Nagle)
Subject: Specifying -model for MPW C++
Date: 14 Apr 92 17:13:27 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)


     The MPW C and C++ compilers don't seem to be updated together as of
MPW 3.2.  C will accept "-model farData" and "-bigseg", but C++ doesn't
understand these yet.  "-m" seems to allow big objects, but linker
warnings about segments > 32K still appear.  What's the right way to
use large objects in MPW C++?

                    John Nagle

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 17 Apr 92 00:41:24 GMT
Organization: MacDTS Mongols

In article <6![e-mail]>, [e-mail] (John Nagle) writes:
>
>
>      The MPW C and C++ compilers don't seem to be updated together as of
> MPW 3.2.  C will accept "-model farData" and "-bigseg", but C++ doesn't
> understand these yet.  "-m" seems to allow big objects, but linker
> warnings about segments > 32K still appear.  What's the right way to
> use large objects in MPW C++?

>From the MPW 3.2 C++ release notes, ETO#7:

    A new option: -model far turns on 32-bit data and code references. By
default, (Rmodel nearS) these references are A5-relative. -model far allows
 a larger address space than the traditional Macintosh model.
    If you do not have any classes derived from PascalObject, all MPW C++
does with -model far is to pass it along to the C compiler, and the
C compiler generates all the 32-bit references.

We didn't implement -model FarData/-model FarCode yet, it might happen
in future.

Cheers,
Kent

---------------------------

From: [e-mail] (Christopher Tate)
Subject: diskInserted events
Date: 14 Apr 92 18:27:24 GMT
Organization: Penn State University

In article <[e-mail]>, [e-mail] (Jim Reekes)
says:
>
>All applications should be checking for diskInserted events.
>

Be that as it may, what should my app be *doing* with them when it
sees them?  I have yet to write an application that needed to know
about these events, so why should I bother looking at them.

Of course, I *am* passing everyEvent as my event mask, but I got the
impression you weren't talking about that....

- -------
Christopher Tate     | Cryptogram #17:
[e-mail] |
[e-mail]  | "NYO XFJ BCFGJ ZFJN MQWJVU EGYZ XQWBSGCJ.  QYT
- ---------------------|  ZOXQ HFMWCJXC NYO QFDC, EYG WJUMFJXC."
Send me the answer!  |                  -- EGFJABWJ H. PYJCU

+++++++++++++++++++++++++++

From: [e-mail] (Paul Potts)
Date: 15 Apr 92 14:14:03 GMT
Organization: Instructional Technology Laboratory, University of Michigan

In article <[e-mail]> Christopher Tate <[e-mail]> writes:
>In article <[e-mail]>, [e-mail] (Jim Reekes)
>says:
>>
>>All applications should be checking for diskInserted events.
>>
>
>Be that as it may, what should my app be *doing* with them when it
>sees them?  I have yet to write an application that needed to know
>about these events, so why should I bother looking at them.

If you don't handle them, when your app is frontmost and a user inserts
a disk, nothing will happen. Even after they quit, nothing will happen -
the disk won't have been mounted, and they can't drag it into the trash
to get rid of it; they can hit "Eject," but most users will just be confused.
(At least, this is the way it used to work).

You should have a case for diskEvents in
your main event loop; it is also a good idea to add a case for handling
diskEvents to the filter procedures of any modal dialogs you use. If you
do this, then your user can insert disks even while a modal dialog is on
the screen, and still have the system recognize them.

Here is how I do it inside a dialog filter procedure:

if (GetNextEvent(diskMask, &diskEvent) == TRUE)
{
    if (HiWord(diskEvent.message) != 0)
    {
        diskEvent.where.h =    ((screenBits.bounds.right -
                screenBits.bounds.left)/ 2) -
                (304 / 2);
        diskEvent.where.v =     ((screenBits.bounds.bottom -
                screenBits.bounds.top)/ 3)
                - (104 / 2);
        InitCursor();
        DIResult =DIBadMount(diskEvent.where,
            diskEvent.message);
    }

}
/* end of if GetNextEvent test for disk events */

(Note that this is pretty crude code and uses hard-coded values for
the dialog size).

Inside your event loop, you should have a case for a diskEvent.
If the HiWord is not equal to zero, you should call DIBadMount.
You can give it anything you like for the .where field; I put mine
in the middle of the screen. There are probably better ways; this
is pretty quick-and-dirty. If you are in the event loop in a typical
application, you won't need to call InitCursor().

If you need an example, look in the Apple Sample Code for something
like SillyBalls. I can't remember where I found the above code, but
it was probably lifted from some Apple sample code.




- --
Paul Potts - [e-mail]
Un damne' descendant sans lampe,/ Au bord d'un gouffre dont l'odeur
Trahit l'humide profondeur,/ D'e'ternels escaliers sans rampe...
   -Baudelaire on DOS/Windows programming

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 15 Apr 92 21:31:13 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Christopher
Tate) writes:
>
> In article <[e-mail]>, [e-mail] (Jim Reekes)
> says:
> >
> >All applications should be checking for diskInserted events.
> >
>
> Be that as it may, what should my app be *doing* with them when it
> sees them?  I have yet to write an application that needed to know
> about these events, so why should I bother looking at them.
>

If you get a disk-inserted event with a result code of noErr, then you don't
need to do anything. However, if the result code is not noErr, then you should
call DIBadMount.

(There is a caveat to this. I think the Finder calls DIBadMount only on certain
result codes, not all of them. I don't know what result codes it considers
benign enough to not call DIBadMount.)

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

+++++++++++++++++++++++++++

Organization: Penn State University
Date: Thursday, 16 Apr 1992 09:14:05 EDT
From: Christopher Tate <[e-mail]>

In article <[e-mail]>, [e-mail] (Keith Rollin)
says:
>
>[I asked the following:]                                                      r
>>
>> Be that as it may, what should my app be *doing* with them when it
>> sees them?  I have yet to write an application that needed to know
>> about these events, so why should I bother looking at them.
>>
>
>If you get a disk-inserted event with a result code of noErr, then you don't
>need to do anything. However, if the result code is not noErr, then you should
>call DIBadMount.

Ah, this explains quite a bit.  I assumed that since "something else" was
taking care of mounting the disks, "something else" would take care of
the initialization prompt, too.

And, it seems that *LOTS* of applications fail to do this.  One big, big
problem that we have in the PSU public Mac labs (Mac IIsi's, Sys. 7) is
that people get terminally confused by putting a disk in and watching
nothing happen.  MacWrite II (latest version) "eats" bad disks by not
calling DIBadMount, as does Darkside of the Mac 2.4 (is this fixed in
version 3?).  And so does MacPaint 2.0.

At last, I understand why we've been seeing this...  <whew>  And now
I *will* Do the Right Thing and call DIBadMount when appropriate.  Thanks
for the clarifications, everyone.

- -------
Christopher Tate        |  "Computer Science has more real-world
                        |   applications than rotisserie baseball."
[e-mail]    |
Bitnet:  CXT105@PSUVM   |       -- Ben Liblit, next-door neighbor

---------------------------

From: [e-mail]
Subject: THINK C 5.0.2 questions on syntax
Date: 14 Apr 92 19:06:40 GMT
Organization: BC Systems Corporation

I have a couple of questions on THINK C 5.02 syntax and procedures.  My first
question has to do with MENU resources.  I'm compiling the first volume of the
Mac Programming Primmer for THINK C to conform to the new 5.02 standard for
some ppl that have requested it sent be sent to them.  Anyway, in most of the
programs where menus are involed, they don't always keep a handle to ALL of the
menus. ie: they will have a handle to the Apple Menu & edit menu, but not the
File Menu or Special Menu (both of which are accessed more than the rest!!! Any
particular reason for this???

Question number 2 pertains more to THINK C 5.0.2 syntax.  The MOVE_TO_FRONT
constant in the book is -1L but for "compability reasons" it now has to be
(WindowPtr)-1L, typecasted.  What is the purpose for this when it worked just
fine the other way in C 4.05????????!!!!!!!! This is rather confusing to have
some of these things different when trying to learn C!!!!

- --
[e-mail]
Victoria, British Columbia, Canada

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 15 Apr 92 21:28:51 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail]
writes:
>
> I have a couple of questions on THINK C 5.02 syntax and procedures.  My first
> question has to do with MENU resources.  I'm compiling the first volume of the
> Mac Programming Primmer for THINK C to conform to the new 5.02 standard for
> some ppl that have requested it sent be sent to them.  Anyway, in most of the
> programs where menus are involed, they don't always keep a handle to ALL of
the
> menus. ie: they will have a handle to the Apple Menu & edit menu, but not the
> File Menu or Special Menu (both of which are accessed more than the rest!!!
Any
> particular reason for this???

I think the real question is why do those programs keep track of any menu
handles at all, as opposed to just some of them. I _never_ keep track of any
menu handles. I always get them when I need them by calling GetMHandle.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

---------------------------

From: [e-mail] (Michael J. Wolf)
Subject: How to guarantee the colors I want when my app runs?
Date: 15 Apr 92 21:55:06 GMT
Organization: Cardiovascular Image Processing Lab, U of Iowa

I have a color environment.  I have a clut resource and a pltt resource.
I create me CWindows and call SetPalette to my pltt resource.

Now, if I start my app first, then go to others which hog colors, and
then return to my app, the colors are set back up correctly when the
window manager calls ActivatePalette for my windows.

BUT, if I start up something first, like ResEdit and open a 256 clut
and it sucks up all the colors, then when I start up my app, it cannot
and will never get the correct colors.

Also, I am using 4bit images and a 4bit clut (I do SetHandleSize to resize
the clut to be as large as the display can handle, ie: 8bit is 256
ColorInfo records), I also have a 4bit pltt.  Now, if I am in 8 bit mode
my colors get screwed up as well.  If while in my app, I change to 4bit
mode, the colors are still wrong, but if I start in 4bit mode and have
my correct colors, then go to 8bit mode, my colors are correct.

This has gotten me a bit confused as to what might be the problem.

I want my app to be system 6.x and 7.x compatible as well as bw & color
compatible.

All help is appreciated.

M Wolf
[e-mail]



+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Date: 16 Apr 92 15:15:43 GMT
Organization: Kalamazoo College

(I changed the followup;  this _doesn't_ belong in comp.lang.c)

[e-mail] (Michael J. Wolf) writes:
>
>I have a color environment.  I have a clut resource and a pltt resource.
>I create me CWindows and call SetPalette to my pltt resource.
>
>BUT, if I start up something first, like ResEdit and open a 256 clut
>and it sucks up all the colors, then when I start up my app, it cannot
>and will never get the correct colors.
>

It sounds like you just want to use pmTolerant colors.  If you're
creating the pltt yourself, you'll want to do so with the NewPalette()
call, and specify the usage field as pmTolerant.  Don't use
SetHandleSize() to add entries;  use ResizePalette().
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Ceci n'est pas une .signature.

---------------------------

From: [e-mail] (Paul Scott)
Subject: ThinkPascal
Date: 15 Apr 92 07:32:22 GMT
Organization: Stats Pure & Applied Maths, Uni of Adelaide, Australia

I am using ThinkPascal 4.0 with System 6.0.5.  I have three problems associated
with graphics programs.

(1) When using the Text Window, sometimes the text does not appear.  This
appears to be an intermittent fault.  Is there a solution?

(2) When working with cartesian axes, is there any easy way of reversing the
y-axis and corresponding coordinates, so that coordinates on the screen
correspond to 'real life'?! - ie y-axis up instead of down?

(3) I understand there may be a way of rotating 'pictures', although I can find
no mention of this in the manuals.  Can anybody please help?

Paul Scott, Department of Pure Mathematics, University of Adelaide, Australia
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (John E Bush)
Date: 16 Apr 92 12:04:33 GMT
Organization: The Ohio State University

In article <[e-mail]> [e-mail] (Paul Scott) writes:
>I am using ThinkPascal 4.0 with System 6.0.5. I have three problems associated
>with graphics programs.

[Stuff Removed]

>(2) When working with cartesian axes, is there any easy way of reversing the
>y-axis and corresponding coordinates, so that coordinates on the screen
>correspond to 'real life'?! - ie y-axis up instead of down?
>
[Stuff Removed]

All you have to do is take Y max and subtract your value from it.  So, if
Y Max is 200, and you want something plotted 5 pixels from the bottom like
a normal math problem, gave a const value for y_max or something similar and
in your pltting equation say y_max-value.  In the above example, it would
result in the value being plotted at 195.

Eric

---------------------------

From: [e-mail] (ROBIN R. REID)
Subject: Zortech C++
Date: 28 Feb 92 01:05:09 GMT
Organization: University of Denver

I'm looking for opinions about the Zortech C++ compiler being
sold by Symantec.  I am very comfortable using C, and feel that
it's time to move forward.

Any help will be appreciated.



- -------------------------

From: [e-mail] (John Nagle)
Subject:  Zortech C++
Date: 28 Feb 92 16:45:13 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)


      Symantek just announced an upgrade.  Mine hasn't come yet, and
I haven't seen any reports of experiences with it.  The old version is
V2.1r2, and you don't want that one.  I suggest waiting a few weeks and
watching for reports on the new release.

                    John Nagle



- -------------------------

From: [e-mail] (Garry Knox)
Subject:  Zortech C++ (MacApp 3.0)
Date: 28 Feb 92 20:21:09 GMT
Organization: University of Maryland (ASDG)

In article <[e-mail]> [e-mail] (John Nagle) writes:
>
>      Symantek just announced an upgrade.  Mine hasn't come yet, and
>I haven't seen any reports of experiences with it.  The old version is
>V2.1r2, and you don't want that one.  I suggest waiting a few weeks and
>watching for reports on the new release.
>
>                    John Nagle

  Does anyone know if this upgrade will support MacApp 3.0?

-garry



- -------------------------

From: [e-mail] (Cory Kempf)
Date: Tue, 3 Mar 92 20:30:50 EST
Organization: EnigamI, Inc., Nashua, NH

Hi,
I am thinking of dumping ETO in favour of the Zortech compiler.  Thus,
I am looking for oppinions/comments from users of Zortech C++ for the Mac.
If you have used it, please let me know what you think of it.  If
you have dealt with their tech support, etc, PLEASE let me know what
you think of them.  Are the responsive?  Helpful?  etc.

Please send me your oppinions via E-mail.  If there is interest,
I will post a summary.

Thanks,

+C


- -------------------------------------------------------------
Cory Kempf                    EnigamI, Inc.
[e-mail]           ...!decvax!enigami!cory

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 8 Mar 92 01:47:49 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Garry Knox) writes:
>
> In article <[e-mail]> [e-mail] (John Nagle) writes:
> >
> >      Symantek just announced an upgrade.  Mine hasn't come yet, and
> >I haven't seen any reports of experiences with it.  The old version is
> >V2.1r2, and you don't want that one.  I suggest waiting a few weeks and
> >watching for reports on the new release.
> >
> >                    John Nagle
>
>   Does anyone know if this upgrade will support MacApp 3.0?

What I heard, NO.

Cheers,
Kent

- --
Kent Sandvik - Apple DTS  - Dynamic Language Evangelist
[e-mail]
All opinions expressed are my own, and not related to any company or
organization.
Happy, happy, joy, joy!

+++++++++++++++++++++++++++

From: [e-mail] (Cory Kempf)
Date: Thu, 19 Mar 92 21:13:20 EST
Organization: EnigamI, Inc., Nashua, NH


Short Summary: Zortech C++ is slow, buggy, and doesn't work.  Stick
with MPW for now.  Maybe useful in the future, but needs work.

More detailed summary:

Zortech does not have (or is not willing to admit the results of) any
comparative benchmarks between MPW C++ and ZC++.

Slower than MPW C++ with load/dump

ZC++ does not work with MacApp 3.0, nor does in come with any class
library (e.g. TCL).

ZC++ is a partial implimentation of C++ 2.1.  Some stuff in not implimented
(iostreams, for example).  C++ 3.0 features such as templates & exceptions
are not implimented either.

ZC++ does not come with a debugger.  SADE is the recommended debugger.
One person commented that ZC++ does not produce .SYM files, so that
would rule out using SourceBug (I thought that it would also kill
SADE as well! -- Maybe he was mistaken)

ZC++ does not include HandleObject support.

ZC++ Documentation is weak.  Especially w.r.t Mac Interface.

ZC++ has trouble with non-sample applications (e.g. non-trivial code).

Symantec's tech support ain't all that up on the Mac version of the
compiler; one tech support group from all platforms.  They also don't
return calls.

And the final, most damning statement:

"I'm not convinced that it can be used for ANY machintosh native
runable code."

Thanks to all who contributed.

+C


- -------------------------------------------------------------
Cory Kempf                    EnigamI, Inc.
[e-mail]           ...!decvax!enigami!cory

+++++++++++++++++++++++++++

From: [e-mail] (John Nagle)
Date: Sat, 21 Mar 92 06:40:32 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

[e-mail] (Cory Kempf) writes:
>Short Summary: Zortech C++ is slow, buggy, and doesn't work.  Stick
>with MPW for now.  Maybe useful in the future, but needs work.

       According to Symantec support, the new release started shipping
today to existing users who called in for the free upgrade.
(If you have the old version, find your serial number (it's on the back of
one of the disks) and call Symantec's upgrade number, 617-280-2510.
Mine hasn't come yet, so I have no idea if it's any good.

       Kempf is, unfortunately, all too right about the previous release.

                    John Nagle

+++++++++++++++++++++++++++

From: [e-mail] (Stephen Hite)
Date: 22 Mar 92 16:33:12 GMT
Organization: University of North Florida, Jacksonville

In article <1w#[e-mail]> [e-mail] (John Nagle) writes:
>[e-mail] (Cory Kempf) writes:
>>Short Summary: Zortech C++ is slow, buggy, and doesn't work.  Stick
>>with MPW for now.  Maybe useful in the future, but needs work.
>
>
>       Kempf is, unfortunately, all too right about the previous release.
>
>                    John Nagle


   To my knowledge, there's been only one person involved with the
Zortech C++ for the MPW platform...Pat Nelson.  You'd think by now that
Symantec would put a couple of their top Mac people on the project
and become compatible with MacApp 3.0.  Then again, you would have thought
that by now Symantec could have produced a Think C++...they really missed
the boat.

Steve Hite
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Tim W Smith)
Date: 21 Mar 92 06:17:58 GMT
Organization: The Portal System (TM)

> Symantec's tech support ain't all that up on the Mac version of the
> compiler; one tech support group from all platforms.  They also don't
> return calls.

Oh well, Zortech didn't return calls, either.  When it first came out,
they sent me an offer to get it at a reduced price.  I called with some
technical questions, and they promised to FAX me the answers or call
back, and they never did.

Maybe Symantec wants to support Zortech customers in the manner in which
they are accustomed? :-)

                            Tim Smith

+++++++++++++++++++++++++++

From: [e-mail] (John Nagle)
Date: 23 Mar 92 23:53:08 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

[e-mail] (Stephen Hite) writes:
>   To my knowledge, there's been only one person involved with the
>Zortech C++ for the MPW platform...Pat Nelson.  You'd think by now that
>Symantec would put a couple of their top Mac people on the project
>and become compatible with MacApp 3.0.  Then again, you would have thought
>that by now Symantec could have produced a Think C++...they really missed
>the boat.

       It's really sad.  I originally purchased Zortech C++ for the Mac
because I was pleased with their MS-DOS product and needed a compatible
compiler on the Mac.  I was very disappointed.  I had months of anguish,
submitted about five bug reports, and finally bought MPW C/C++.

       The product had such promise.  The global optimizer really does
the hard optimizations right.  It's just the 680x0 code generator that's
broken.  The MS-DOS product never could optimize as much as one would
like because the Intel CPUs just don't have enough registers.  But on
the 68000, much more serious optimizing is possible.  In theory, this
should be a really great compiler.  It just needed serious testing
before shipment, which it didn't get.

        Not only that, but since it's a hard compiler, rather than a
front end for C, an efficient implementation of exceptions is possible.
With some work, Symantec could leapfrog MPW and bring C++ up to the
level documented in Strostrup's latest definition of the language.
C++ with exceptions, and classes that use them properly to protect
themselves, could provide a much more reliable support structure for
Mac programs.  This might provide a path out of the general flakeyness
of Mac programs.

         But I'm not holding my breath.

                    John Nagle

+++++++++++++++++++++++++++

From: [e-mail] (Waqar Malik)
Date: 26 Mar 92 03:22:07 GMT
Organization: Caltech Computer Science


    Does any body have the part number for Zortech C++ for Mac.
    I called but sales person does not seem to know about it.

    Sorry if it is a FAQ.

waQar malik
- --
Waqar Malik                    [e-mail]

"The brain is a wonderful organ: it starts working the moment you get
 up in the morning, and does not stop until you get to school."

+++++++++++++++++++++++++++

From: [e-mail] (Ray Arachelian)
Date: 28 Mar 92 21:44:00 GMT
Organization: FidoNet node 1:2603/204 - Not Even Odd, Forest Hills NY

On 03-20-92, [e-mail] wrote to ALL:

 C> Symantec's tech support ain't all that up on the Mac version of the
 C> compiler; one tech support group from all platforms.  They also don't
 C> return calls.

If Zortech C++ for the Mac sucks so badly, why did Symantec bother to buy
it, especially when they already own Think C?


 * Freddie 1.1 * You have been found guilty of commerce with the devil.

- --
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
 Ray Arachelian - Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (John Nagle)
Date: Tue, 31 Mar 92 18:04:27 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

       Any sign of the new Zortech release announced several weeks ago?
Symantec/Zortech support told me it would ship "tomorrow" over a week ago.

                    John Nagle

+++++++++++++++++++++++++++

From: [e-mail] (Garry Knox)
Date: 31 Mar 92 20:12:36 GMT
Organization: University of Maryland

In article <[e-mail]> [e-mail] (John Nagle) writes:
>
>       Any sign of the new Zortech release announced several weeks ago?
>Symantec/Zortech support told me it would ship "tomorrow" over a week ago.
>
>                    John Nagle

  Get my copy last friday. Included in the package was a new manual, with
Symantec on the cover. I haven't spent too much time with it since it does not
support MacApp 3.0. They claimed in the release notes that they were working
with the MacApp team to "determine" the problem... :-/

- -garry


+++++++++++++++++++++++++++

From: [e-mail] (Jim Bailey)
Organization: Lexicon, Inc., Waltham, MA
Date: Tue, 31 Mar 1992 23:46:17 GMT

In article <[e-mail]> [e-mail] (Ray Arachelian) writes:

   On 03-20-92, [e-mail] wrote to ALL:

    C> Symantec's tech support ain't all that up on the Mac version of the
    C> compiler; one tech support group from all platforms.  They also don't
    C> return calls.

   If Zortech C++ for the Mac sucks so badly, why did Symantec bother to buy
   it, especially when they already own Think C?

I think they bought Zortech for the MS-DOS, OS/2 compiler, and got the
MPW thrown in for free.  They probably didn't give the MPW version
much weight in the decision.  Symantec is much bigger in the MESS-DOS
world than in the Mac world.  At least they haven't outright killed it
yet.

- --
"The Beatles were elevator music in my lifetime 'Yummy Yummy Yummy (I've Got
Love In My Tummy)' had more impact on me" -- Michael Stipe of R.E.M.
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (John Nagle)
Date: 1 Apr 92 23:07:52 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)


        The new release, V2.1, just came.  From the manual, it appears to have
exactly the same limitations as last year's model.  Still no math
coprocessor support, no templates, no exceptions, no MacApp 3.0...
Haven't installed it yet, and probably won't since most of what I do
slows down by an order of magnitude without inline math support.

                    John Nagle

+++++++++++++++++++++++++++

From: [e-mail] (Mike Alexander)
Date: 4 Apr 92 20:59:48 GMT
Organization: University of Michigan, ITD-Research Systems




Mike Alexander              Internet:       [e-mail]
University of Michigan      Bitnet:         USERMTA@UMICHUM
ITD - Research Systems      AppleLink:      UMICH
                            America Online: MAlexander

+++++++++++++++++++++++++++

From: [e-mail] (Mike Alexander)
Date: 4 Apr 92 21:54:39 GMT
Organization: University of Michigan, ITD-Research Systems

<Oops, I was using an unfamiliar news reader and lost my text>

I installed the new version and converted one medium sized program to
compile
with it, but probably won't switch over to it regularly. It seemed to
produce
correct code for toolbox calls now, unlike the previous version. Also the
SYM
information produced is now compatible with Jaski's Debugger, which is
important
to me. However, they still distribute their own version of CIncludes,
which is
based on an obsolete version from Apple. Fortunately, most of the files
are
unchanged by Zortech, and it is possible to substitute the current Apple
ones
without too much trouble.


Mike Alexander              Internet:       [e-mail]
University of Michigan      Bitnet:         USERMTA@UMICHUM
ITD - Research Systems      AppleLink:      UMICH
                            America Online: MAlexander

+++++++++++++++++++++++++++

From: [e-mail] (Tony Wingo)
Date: 8 Apr 92 17:13:52 GMT
Organization: Apple Computer

In article <[e-mail]>, [e-mail] (Ray Arachelian) writes:
>
> On 03-20-92, [e-mail] wrote to ALL:
>
>  C> Symantec's tech support ain't all that up on the Mac version of the
>  C> compiler; one tech support group from all platforms.  They also don't
>  C> return calls.
>
> If Zortech C++ for the Mac sucks so badly, why did Symantec bother to buy
> it, especially when they already own Think C?

Probably because Zortech is a major player in the MSDOS C++ field, and they
wanted into that market.

- -tony

>>usual disclaimer<<

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 10 Apr 92 01:32:48 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Jim Bailey)
writes:
> In article <[e-mail]>
[e-mail] (Ray Arachelian) writes:
>
>    On 03-20-92, [e-mail] wrote to ALL:
>    If Zortech C++ for the Mac sucks so badly, why did Symantec bother to buy
>    it, especially when they already own Think C?
>
> I think they bought Zortech for the MS-DOS, OS/2 compiler, and got the
> MPW thrown in for free.  They probably didn't give the MPW version
> much weight in the decision.  Symantec is much bigger in the MESS-DOS
> world than in the Mac world.  At least they haven't outright killed it
> yet.

This is just speculation, but why would a company kill a compiler that
supposedly will work under both environments, something which is a rare
thing today? It sounds market-wise silly to kill one of the selling options.
Remember the tick box wars against Borland and Microsoft...

Cheers,
Kent Sandvik
Dynamic Language Revivalist

+++++++++++++++++++++++++++

From: [e-mail] (Stephen Hite)
Date: 15 Apr 92 20:46:58 GMT
Organization: University of North Florida, Jacksonville

In article <[e-mail]> [e-mail] (Kent Sandvik) writes:
>
>This is just speculation, but why would a company kill a compiler that
>supposedly will work under both environments, something which is a rare
>thing today? It sounds market-wise silly to kill one of the selling options.
>Remember the tick box wars against Borland and Microsoft...
>
>Cheers,
>Kent Sandvik
>Dynamic Language Revivalist

  Well, Kent,  I think it comes down to logistics and time.  The
logistics problem is that Walter Bright lives in Seattle, WA and Symantec
is doing their development in Mass.  It's kinda tough to get inside his
head over the phone and you know he's not in Mass enough to be very useful
to others on the project.  The time problem is they've got to get more
eyes looking at the compiler and linker code to where they don't have to
rely on Walter as much.  On the positive side, once they regroup (i.e. Mac
product supports MacApp 3.0), Symantec could be in a good market
position (although certainly not a dominant one in the short term).

  Symantec's largest failing is that they should have seen the C++ move
coming years ago and done something in-house about it.  As they've just
learned, buying other company's products can come with just as many
problems and expenses as "inventing it here."


Steve Hite
[e-mail]

---------------------------

End of C.S.M.P. Digest
**********************